One problem with this is that it won't ever try to build the changes being released. It'll just verify that the existing examples build against the latest version.

A couple of solutions are possible:

1. We modify the examples to depend on the repository they're included in (i.e. don't go to GitHub, instead depend on "../.."). Then, update the script to make tags locally, test building the examples, then publish the tags to GitHub if building succeeds.
   • The main problem with this is that the Package.swifts included in our examples aren't really representative of how a user would actually include our project. This may not really be a problem given the example Package.swift we include in the readme.
2. We search/replace the version string in the examples' Package.swifts and verify they build. Seems messy but it gets the job done.
3. Assuming we'll have a branch for each minor version, we could point the examples to the latest version branch, verify they build, then publish the version tags afterwards.
   • The main problem here is the same problem here is the same as the first in that it will have a nonstandard Package.swift.
   • As a side note, we'll probably want branches for at least every major version to allow for backporting. We probably want one for each minor version too.

I'm not really sure which of these would be the best approach, or really if any of these is the right one. What do you think?

hmmmmm...... I think we should avoid having non-standard Package.swifts. option 2 seems reasonable.
option 2 seems better, but agree it's rather messy.
we could also just make running this script a required step of the release process that occurs right after we publish the tags.